System and method for communicating over a network with a medical device

ABSTRACT

A device is provided for connecting a medical apparatus to a network. The device collects data from the medical apparatus and performs a variety of processing functions, such as trending, protocol translation, generating reports, etc. related to the collected data. The device then transmits the collected data over a network to interested parties. In some implementations, the device can transmit the collected data as an email message.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/004,799, filed Jan. 11, 2011, which claims the benefit of U.S.provisional application No. 61/296,390, filed Jan. 19, 2010, and U.S.provisional application No. 61/376,019, filed Aug. 23, 2010, thedisclosures of which are hereby incorporated by reference in theirentirety.

BACKGROUND

1. Field

The present disclosure relates to computer systems for communicatingover a network with a medical device.

2. Description of the Related Art

The sharing of patient data between medical institutions and health careproviders presents a variety of challenges. These challenges may includeprivacy, expense, accessibility, etc.

In 1996, President Clinton signed the Health Insurance Portability andAccountability Act (HIPAA). Among other things, this law (i) ensures thecontinuity of healthcare coverage for individuals changing jobs; (ii)includes a provision that impacts the management of health information;(iii) seeks to simplify the administration of health insurance; and (iv)aims to combat waste, fraud and abuse in health insurance andhealthcare.

The Department of Health and Human Services has issued variousregulations to implement these new requirements. These regulationsimpact all healthcare organizations that electronically create, storeand/or transmit healthcare data. Among other things, HIPAA requires thesecure storage and transmission of electronic healthcare data.

Setting up Virtual Private Networks (VPNs) or running point-to-point T1lines can provide the necessary secure transmission of electronichealthcare data. However, VPNs and T1 lines can be cost prohibitive inmany situations.

Alternatively, the so-called secure shell (SSH) technology and rsyncprotocol can be used to provide a suite of network connectivity toolswhich enable secure transmission of electronic healthcare data bycreating a minimal subset of a many-to-one virtual network running overthe public Internet.

In addition to the foregoing, medical institutions (e.g., hospitals)typically implement firewalls to limit outside access to their internalcomputer networks. Among other things, hospital firewalls will typicallyblock outside attempts to access any medical data on their internalmedical devices. One example of such a device is described in U.S. Pat.No. 7,040,318, the disclosure of which is hereby incorporated byreference. Outside access to such devices, even if they included anembedded server as described, is typically blocked by medicalinstitutions.

Unfortunately, in many situations, it can be important for a healthcareprovider to have access to the medical data on internal medical devicesoutside the healthcare institution. For example, it may be desirable topass collected medical data from the hospital to a physician foranalysis. In circumstances such as these, the aforementioned securitysystems for storing and transmitting electronic healthcare data canimpede the electronic transfer of the data.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects and many of the attendant advantages of this disclosure willbecome more readily appreciated as the same become better understood byreference to the following detailed description, when taken inconjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram of the system according to one embodiment.

FIG. 2 illustrates the components of the medical device of FIG. 1, inaccordance with one embodiment of the invention

FIG. 2A illustrates one system configuration for the medical device ofFIG. 2, in accordance with one embodiment of the invention.

FIG. 2B illustrates an alternative system configuration for the medicaldevice of FIG. 2, in accordance with one embodiment of the invention.

FIG. 2C illustrates another system configuration for the medical deviceof FIG. 2, in accordance with one embodiment of the invention.

FIG. 2D illustrates a back view of an exemplary hardware configurationfor the medical device of FIG. 2, in accordance with one embodiment ofthe invention.

FIG. 2E illustrates a front view of an exemplary hardware configurationfor the medical device of FIG. 2, in accordance with one embodiment ofthe invention.

FIG. 3 illustrates the components of the healthcare provider system ofFIG. 1, in accordance with one embodiment of the invention.

FIG. 4 illustrates a sequence of steps that may be performed by themedical device of FIG. 1, in accordance with one embodiment of theinvention.

FIG. 5 illustrates a sequence of steps that may be performed by thehealthcare provider system of FIG. 1, in accordance with one embodimentof the invention.

FIG. 6 is a block diagram of the system according to another embodiment.

FIG. 7 illustrates one example of architecture for encryption, inaccordance with one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the invention will now be described with reference to theaccompanying figures, wherein like numerals refer to like elementsthroughout. The terminology used in the description presented herein isnot intended to be interpreted in any limited or restrictive manner,simply because it is being utilized in conjunction with a detaileddescription of certain specific embodiments of the invention.Furthermore, embodiments of the invention may include several novelfeatures, no single one of which is solely responsible for its desirableattributes or which is essential to practicing the inventions hereindescribed.

Systems, methods, and computer-readable media are disclosed forcommunicating over a network with, and obtaining medical data from, amedical device. More specifically, systems, methods, and computerreadable media are disclosed for enabling an entity external to amedical institution that has a firewall or other network security systemto communicate with a medical device in the medical institution.

For example, in one embodiment, a medical device is provided thatperforms a requested action. The medical device then generates aresponse that is dependent upon the requested action and sends thegenerated response to a node on a network from the medical device as anemail message.

In another embodiment, a method of communicating with a medical deviceover a network is provided. The method comprises receiving over thenetwork, by the medical device, a request to perform some action from anode, such as, an email server. The medical device then performs therequested action, wherein the request is received as an email. FIGS. 1-7illustrate various exemplary embodiments of the invention in moredetail.

FIG. 1 illustrates an exemplary system environment 200 for implementingembodiments of the invention. As shown in FIG. 1, system 200 maycomprise multiple computer systems or machines, such as, a healthcareprovider system 210 (which may be implemented as a “client”), a medicaldevice 100 containing a data server 105, and an email server 220. Thesevarious components may be connected and communicate with one anotherthrough any suitable network 230, including the Internet. Email server220 may be a conventional, preexisting system operated by its respectiveentity.

Healthcare provider system 210 may comprise any computing system used toperform tasks of some embodiments of the invention. In one embodiment,healthcare provider system 210 is maintained by a healthcare providerthat desires access to medical device 100. Healthcare provider system210 is provided a web interface such that a healthcare provider mayinteract with email server 220. Healthcare provider system 210 may belocated at any location, such as a healthcare provider's home, office,or kiosk, etc. Additionally, one skilled in the art will appreciate thatany number of healthcare provider systems may be provided to enableaccess to medical device 100 by healthcare providers.

Email server 220 is maintained by an entity that provides email serviceto employees or people associated with a medical institution. Forexample, email server 220 may be maintained by Google, Yahoo, etc. In apreferred embodiment, email server 220 is maintained by a hospital.

Medical device 100 is maintained by a medical institution. Medicaldevice 100 is used by a medical institution to collect data frompatients and to treat patients. Medical device 100 includes a dataserver 105. In a preferred embodiment, medical device 100 is aventilator including a data server 105, such as the ventilator describedin U.S. Pat. No. 7,040,318 and incorporated herein by reference. In analternate embodiment, medical device 100 may be an implanted medicaldevice, such a defibrillator, pacemaker, etc., that communicates withdata server 105. That is, the implanted medical device may communicatewith data server 105 via a wireless link, such as an RF link. A skilledartisan will appreciate that a variety of other configurations andcommunication mechanisms are possible in embodiments of the presentinvention. Further, in a preferred embodiment, medical device 100 isassociated with a unique email address.

As shown in FIG. 1, in a preferred embodiment, medical device 100 islocated within a medical institution and healthcare provider 210 islocated outside of the medical institution. Some embodiments of thepresent invention enable communication between healthcare provider 210and medical device 100 even if the medical institution has establishedsecurity measures (e.g., firewalls), as discussed above. In someembodiments of the present invention, email server 220 may be locatedeither inside or outside the medical institution. A skilled artisanwould appreciate that healthcare provider system 210 located within themedical institution would also be configured to communicate with medicaldevice 100 in some embodiments of the present invention. A skilledartisan would also appreciate that in some embodiments of the presentinvention, healthcare provider system 210 would be configured tocommunicate with medical device 100 even if the medical institution hadnot established the security measures discussed above.

FIG. 1 also shows an exemplary sequence of steps (1-5) that may beperformed by system environment 200 in one embodiment. Thecommunications shown in FIG. 1 occur over one or more computer networks,such as the Internet and/or an internal network of the medicalinstitution. First (1), healthcare provider system 210 requests theperformance of some action associated with the medical device (e.g., arequest for a particular item or type of data), and the request is sentto email server 220. This request may be in the form of an email. Thisrequest may be generated automatically by a special application, e.g.,on input from a human operator. The type of action to be performed maybe specified explicitly or implicitly in the request message. Next (2),email server 220 forwards the request to medical device 100. Then (3),medical device 100 performs the requested action and (4) sends aresponse to email server 220. This response may be in the form of anemail reply, and may include physiologic and/or other data collected bythe medical device 100 from one or more patients. Finally (5), emailserver 220 forwards the response to healthcare provider system 210. Moredetail regarding the sequence of steps will be discussed below inrelation to FIGS. 4 and 5. Because the communications (1) and (5)between the medical institution and the healthcare provider system 210can be email communications, they are not susceptible to being blockedby the medical institution's Internet firewall.

Although a single medical device is depicted in FIG. 1, many differentmedical devices 100 that operate as described above may be providedwithin the medical institution, and each may have a unique emailaddress. In addition, multiple distinct healthcare provider entities andsystems 210 may communicate with a particular medical device using themethod shown in FIG. 1.

In some cases, multiple email addresses may be assigned to a givenmedical device 100, and the type of operation performed by the medicaldevice 100 in response to the request may depend on the address used.For instance, an email sent to device123-data1@hospital.com may causethe device 100 to return one type of medical data, while an email sentto device123-data2@hospital.com may cause the device 100 to returnanother type of data.

FIG. 2 illustrates a more detailed diagram of an exemplary medicaldevice 100 of some embodiments of the present invention. In thisexample, medical device 100 facilitates the communication of medicaldata and in particular communication of medical data outside of medicalinstitutions in the preferred embodiment.

As illustrated in FIG. 2, medical device 100 includes an embeddedcomputing platform 110, an embedded input module 120, an embedded outputmodule 130, and an embedded memory 135. Embedded computing platform 110may be adapted to process input information received from embedded inputmodule 120. Embedded computing platform 110 may further be adapted toprovide output information to embedded output module 130.

Embedded computing platform 110 may comprise a general purpose computer(e.g., a personal computer, network computer, server, or mainframecomputer) having a processor that may be selectively activated orreconfigured by a computer program to perform one or more methods of thepresent invention. Embedded computing platform 110 may also beimplemented in a distributed network. Alternatively, embedded computingplatform 110 may be specially constructed for carrying-out methods ofthe present invention, such as through the use of application-specificcircuitry.

Embedded input module 120 may include an input port 122 and/or anembedded network interface 126. Input port 122 may comprise one or moreports that may be connected to patients, other medical devices, othercomputing devices, etc. to collect medical data that is to becommunicated. Embedded network interface 126 may receive informationover any type of network (not shown), such as a telephony-based network(e.g., PBX or POTS), a local area network, a wide area network, adedicated intranet, and/or the Internet. Embedded computing platform 110may also access data stored on embedded storage device 124. Embeddedstorage device 124 may include a memory, such as RAM or ROM memory, thatcontains instructions or data for performing one or more methods of thepresent invention.

Embedded output module 130 may include an output port 132 and anembedded output interface 134. Output port 132 may be connected topatients, other medical devices, other computing devices, etc. totransmit medical data, commands, requests, etc. that are received.Output port 132 may also be used to control patients, other medicaldevices, other computing devices, etc. Embedded output interface 134 maybe used to provide relevant information to the interested parties viathe Internet, email, fax, page, etc. or save the information on acomputer readable medium.

FIG. 2A shows one example of a system configuration that can be used toimplement medical device 100. In this embodiment, medical device 100 maycomprise medical apparatus 101 and network bridge 102. Medicalapparatus, as described above, is used by a medical institution tocollect data from patients and to treat patients. Medical apparatus 101includes data server 105. As also discussed above, in a preferredembodiment, medical apparatus 101 is a ventilator including a dataserver 105, such as the ventilator described in U.S. Pat. No. 7,040,318and incorporated herein by reference. In an alternate embodiment,medical apparatus 100 may be an implanted or implantable medical device,such a defibrillator, pacemaker, etc., that communicates with dataserver 105. Medical apparatus 101 can be configured to provide one ormore ports to communicate with patients or external devices. Forinstance, medical apparatus 100 may include one or more ports configuredto provide the functionality of input port 122 and/or output port 132.Data server 105 is configured to include embedded computing platform110, embedded memory 135, and embedded storage device 124, as describedabove (not shown). Data server 105 is configured to manage the medicaldata and provide the functionality discussed below. For example, dataserver 105 may store and analyze collected medical data. For instance,data server 105 may generate reports, charts, trending or otherquantitative analysis, web pages for the medical data or applets forviewing the medical data.

Medical apparatus 101 also has one or more ports configured to connectto network bridge 102. Network bridge 102 is configured to provide thefunctionality of network interface 126 and/or output interface 134. Forinstance, network bridge 102 may be a wireless transceiver or modem thatconnects medical apparatus 101 to network 230. As another example,network bridge 102 may be an Ethernet card or integrated circuit.Network bridge 102 transmits data from medical apparatus 101 to network230 and receives data from network 230 and sends data back to medicalapparatus 101. In order for network bridge 102 to receive and send data,network bridge 102 can be configured to translate the data to variousformats. For example, network bridge 102 can be configured to translateserial data from medical apparatus 101 to TCP/IP or UDP packets fortransmission over network 230. A skilled artisan will appreciate thatnetwork bridge 102 may perform a variety of protocol translations knownin the art.

FIG. 2B shows another example of a system configuration that can be usedto implement medical device 100. In this embodiment, medical device 100may also comprise medical apparatus 101 and network bridge 102, asdescribed above in reference to FIG. 2A. Medical apparatus 101, as alsodiscussed above in reference to FIG. 2A, can be used by a medicalinstitution to collect data from patients and to treat patients. As alsodiscussed with reference to FIG. 2A, medical apparatus 101 can also beconfigured to provide one or more ports to communicate with patients orexternal devices, such as input port 122 and/or output port 132.

In contrast to FIG. 2A, data server 105 comprising embedded computingplatform 110, embedded memory 135, and embedded storage device 124 maybe included in network bridge 102 instead of medical apparatus 101. Dataserver 105, as discussed above, is configured to manage the medical dataand provide the functionality discussed below. One advantage of thisalternative configuration, in this embodiment, is that the processing bythe data server 105 is provided by network bridge 102 instead of medicalapparatus 101. As a consequence, medical apparatus 101 does not have tobe programmed or configured to provide processing of data server 105.That is, network bridge 102 can be connected to any medical apparatus101 and the processing of data server 105 can be provided withoutprogramming or configuring medical apparatus 101. In addition, sincestorage of medical data is handled by data server 105, including dataserver 105 in network apparatus 102 may require less storage spacerequirements by medical apparatus 101.

Another advantage of the alternative embodiment is that medicalapparatus 101 of FIG. 2A is configured to output data in a specifiedformat so that the medical data can properly be processed by networkbridge 102. For example, if network bridge 102 is a wirelesstransceiver, medical apparatus 101 must be configured to output medicaldata in the proper wireless protocol standard so that it can beprocessed by the wireless transceiver. As such, if a different networkbridge 102 is used, medical apparatus 101 would have to be re-configuredto output medical data in a different format. This can be done byreplacing medical apparatus 101 with a different medical apparatus ormanually updating the functioning of medical apparatus 101 by uploadinga different version of the software that enables outputting the medicaldata in a different format. This can be troublesome if multiple medicalapparatuses have been installed because multiple medical apparatuses mayhave to be replaced or updated manually.

However, these challenges can be overcome in the embodiment of FIG. 2B.In this embodiment, medical apparatus 101 can be configured to outputmedical data in a standard format to network bridge 102. Then dataserver 105 of network bridge 102 can be adapted to format the receivedmedical data in a specified format for transfer to network 230. Thisembodiment enables the communication of medical data over a variety ofnetworks using a variety of different protocols without re-configuringor programming medical apparatus 101. Medical apparatus 101 can stillcommunicate medical data in a standard format, such as using a RS232port, and network bridge 102 can be reconfigured to format the medicaldata in a different format as may be needed.

To enable proper reformatting of the received medical data, networkbridge 102 can be adapted to map the received medical data in a standardformat to medical data in a specified format for transmission to network230. That is, network bridge 102 may have a mapping table thatassociates medical data in the standard format to the related variables,fields for the formats for transmission to network 230. A skilledartisan will also appreciate that the standard format can be any formatdesired.

FIG. 2C shows a more detailed embodiment of medical device 100. Asdescribed above in reference to FIG. 2B, medical device 100 can belocated in a hospital and comprise medical apparatus 101 and networkbridge 102. Medical apparatus 101 can be configured to output medicaldata in a standard format to network bridge 102. Medical apparatus 101can be a ventilator and can be connected to network bridge 102 via anRS232 port, as shown in FIG. 2C. Data server 105, as discussed abovewith reference to FIG. 2, can comprise embedded computing platform 110(e.g., a processor) and embedded storage device 124. Embedded storagedevice 124 may contain instructions and/or data for performing one ormore methods of the present invention by embedded computing platform110. For example, as shown, embedded storage device 124 may includeexecutable program instructions for performing protocol translation, forproviding an email, notification/alarm, web, database/SQL, etc. service,for managing the control of medical apparatus 101, for generatingreports or applets, for performing data analysis, for performing datastorage and management, etc. Data analysis can constitute any kind ofanalysis that could be performed by data server 105. For instance, dataserver 105 could perform trending or other statistical analysis on themedical data, could perform data mining or merging on the medical data,could perform data modeling of the medical data, etc. A skilled artisanwould appreciate that data server 105 may also provide a medicalrecommendation or diagnosis service based on the data analysis. Forexample, data server 105 may determine a diagnosis or recommendation fortreatment to provide to a user after analyzing the data for trends orpatterns. Similarly, data server 105 can perform analysis of the medicaldata in comparison to previously received or stored medical data anddetect any patterns, any alarms conditions, any trends, any diagnosis,etc. and notify any responsible user. A skilled artisan would alsoappreciate that a variety of other functions could be performed by dataserver 105. Network bridge 102 can be connected to network 203 via aport. Network 230 is connected to a client device, such as healthcareprovider system 210 that in a preferred embodiment includes a webbrowser.

For instance, first, healthcare provider system 210 may request theperformance of some action associated with the medical device (e.g., arequest for a particular item or type of data), and the request is sentnetwork bridge 102. This request may be in the form of an email. Thisrequest may be generated automatically by a special application, e.g.,on input from a human operator. The type of action to be performed maybe specified explicitly or implicitly in the request message. Next,network bridge 102 may translate the received request into a standardformat for transmission to medical apparatus 101. For example, networkbridge 102 may translate the email request into the standard format fortransmission via the RS232 port. Then, medical apparatus 101 performsthe requested action and sends a response to network bridge 102 in thestandard format. Network bridge 102 then can translate the receivedresponse into a specified format for transmission to healthcare providersystem 210. This response may be in the form of an email reply, and mayinclude physiologic and/or other data collected by medical apparatus 101from one or more patients. Network bridge 102 may also perform thevarious functions discussed above, such as generating reports,generating applets, performing data analysis, performing data storageand management, etc More detail regarding the sequence of steps will bediscussed below in relation to FIGS. 4 and 5.

FIGS. 2D and 2E illustrate an exemplary hardware configuration (circuitboard) that may be used for network bridge 102. FIG. 2D illustrates theback side of the circuit board, and FIG. 2E illustrates the front side.As shown in FIG. 2D, the board may comprise an interface port to connectto medical apparatus 101, such as a ventilator. As shown in FIG. 2E, theboard may also comprise a CPU, USB ports, a serial port, an Ethernetport, a power switch, and an external power port. A skilled artisan willappreciate that the serial port, USB ports, and/or Ethernet port may beused to connect to other devices or networks, as discussed above. Askilled artisan will also appreciate that a variety of other hardware orboard configurations may be used in embodiments of the presentinvention.

FIG. 3 illustrates a more detailed diagram of an exemplary healthcareprovider system 210 of some embodiments of the present invention. Inthis example, healthcare provider system 210 facilitates the access tomedical data.

As illustrated in FIG. 3, healthcare provider system 210 includes aprovider computing platform 211, a provider input module 212, a provideroutput module 215, a provider memory 220, and a patient database 221.Provider computing platform 211 may be adapted to process inputinformation received from provider input module 212. Provider computingplatform 211 may further be adapted to provide output information toprovider output module 215. Additionally, provider computing platform211 may access information in patient database 221 for use in performingmethods of the present invention.

Provider computing platform 211 may comprise a general purpose computer(e.g., a personal computer, network computer, server, or mainframecomputer) having a processor or group of processors that may beprogrammed by executable code modules to perform one or more methods ofthe present invention. Provider computing platform 211 may also beimplemented as set of two or more networked computing devices or nodesin a distributed network. Alternatively, provider computing platform 110may be specially constructed (e.g., via application-specific circuitry)for carrying out methods of the present invention.

Provider input module 212 may include a provider input device 213 and/ora provider network interface 214. Provider input device 213 may beimplemented using a keyboard, mouse, speech recognition device, and/orother data entry device. Provider network interface 214 may receiveinformation over any type of network (not shown), such as atelephony-based network (e.g., PBX or POTS), a local area network, awide area network, a dedicated intranet, and/or the Internet. Providercomputing platform 212 may also access data stored on provider storagedevice 219. Provider storage device 219 may include a memory, such asRAM or ROM memory that contains instructions or data for performing oneor more methods of the present invention.

In accessing medical data, provider input module 212 may be used toenter or obtain medical data from medical institutions, commands to besent to medical institutions, requests to be sent to medicalinstitutions, etc. Such information and requests may be obtained, forexample, from an employee, from provider storage device 219, and/or fromanother computing system via provider network interface 214. Providercomputing platform 211 may store such information received from providerinput module 212 in patient database 221.

As further described below, provider computing platform 211 may use thestored patient information to generate reports, alerts, and the like forhealthcare providers. Provider computing platform 211 may then outputthe requested information via provider output module 215.

Provider output module 215 may include a printer 216, a provider outputinterface 217, and/or a display 218. Printer 216 may be used to providea printout to interested parties of relevant information, such medicaldata collected from etc. Provider output interface 217 may be used toprovide such relevant information and/or other information to theinterested parties via the Internet, email, fax, page, etc. or save theinformation on a computer readable medium. Display 218 may be used toprovide such relevant information to interested parties visually.

Patient database 221 may include patient account data and healthcareprovider data. Patient account data preferably includes a record of allpersonal data associated with patients connected to medical device 100,such as name, address, telephone number, driver's license number, socialsecurity number, credit card account number, checking account number,etc. Healthcare provider data preferably includes records of all reportsgenerated for the healthcare providers, alerts generated for thehealthcare providers, patients associated with the healthcare providers,requests made by the healthcare providers. Healthcare provider data mayalso include the healthcare provider's membership identification (“ID”)and password. The information to be stored in patient database 221 maybe entered or obtained using provider input module 212.

FIG. 4 illustrates a flowchart of an exemplary process for communicatingmedical data of some embodiments of the present invention. This processmay be implemented by the medical device 100, and may be embodied insoftware and/or application-specific circuitry. Although the steps ofthe communication process are described as being performed in aparticular order, one skilled in the art will appreciate that thesesteps may be performed in a modified or different order, or in anembodiment utilizing less than all of the steps described below.Further, one or more of the steps in FIG. 4 may be performedconcurrently or in parallel.

First, embedded computing platform 110 receives a request (Step 410)generated by healthcare provider system 210. The request typicallyexplicitly or implicitly specifies a particular action to be performedby medical device 100. In one embodiment, the request from thehealthcare provider is sent to email server 220 which then sends therequest to medical device 100. The request is received over network 230.In a preferred embodiment, the requests are received as emails using thePOP protocol. That is, the healthcare provider sends the request toemail server 220 using SMTP or IMAP protocols and then email server 220forwards the email to the unique email address associated with medicaldevice 100 using POP. Sending the requests as email messages may allowthe communication and sending of data to medical device 100 even thoughthe medical institution where medical device 100 exists has establisheda firewall. Embedded computing platform 110 may, in one embodiment,periodically check or request email server 220 to send medical device100 any emails or requests that are to be sent to medical device 100. Inanother embodiment, email server 220 sends emails or requests directlyto medical device 100 without waiting for a request. That is, in such anembodiment, medical device 100 does not periodically request or checkfor emails but receives the emails directly from email server 220 asthey are received. Further, a skilled artisan will appreciate that avariety of other protocols could be used in embodiments of the presentinvention. For example, FTP, FTPS, SSH, HTTP, HTTPS, VoIP, GPS, CDMA,GSM, etc. may be used in some embodiments of the present invention.Moreover, a skilled artisan will appreciate that the email server 220 oranother intermediate system can be configured with appropriate rules toprevent the medical device 100 from receiving unwanted messages or spam.For example, an incoming email addressed to the medical device 100 canbe blocked if it is not from a trusted source, and/or if the messageportion is not formatted properly (e.g., does not include a validcommand or authentication signature).

Next, embedded computing platform 110 performs the requested action(Step 420). As part of this step, embedded computing platform 110 mayparse the received request or email and perform the action as requested.A skilled artisan will appreciate that in some embodiments of thepresent invention, a protocol for communicating data between medicaldevice 100 and healthcare provider system 210 via standard emailmessages may be established. As such, parsing of the request would bepossible based on the defined protocol using conventional methods as isknown in the art. If the received request relates to collecting medicaldata, embedded computing platform 110 may collect the requested medicaldata. If the received request relates to performing some other action(i.e., set parameters on a connected device, take an image, control somevalve, etc.), embedded computing platform 110 can perform the requestedaction.

For example, in the preferred embodiment, various settings for theventilator may need to be configured in order for them to beadministered properly. Examples of commonly required settings to controla ventilator include: Peak Inspiratory Pressure (PIP) setting-limitingthe peak pressure during inspiration of air; and Positive End ExpiratoryPressure (PEEP) setting-limiting the peak pressure at the end ofexpiration of air. Many other ventilator settings may also becontrolled. In addition, some ventilators are equipped with varioussensors so that a patient caregiver may monitor the condition of thepatient through the ventilator. Examples of commonly monitoredparameters for a ventilator include Mean Airway Pressure (MAP)—the meanpressure measured within the airway during the breathing cycle; andTidal Volume Inspired (Tvi)—measured volume of gas inhaled by thepatient during a normal breath. Many other ventilator parameters mayalso be monitored. As a consequence, embedded computing platform 110 ofthe ventilator in the preferred embodiment may perform some actionrequested. Exemplary actions may include, “set PIP,” “get ventilatordata,” “get MAP,” “take image,” etc. A skilled artisan will appreciatethat a variety of other actions are possible in embodiments of thepresent invention.

In an alternate embodiment, embedded computing platform 110automatically performs some action without waiting for a request (i.e.,step 410 is skipped). In this embodiment, embedded computing platform110 can be configured to perform some action automatically atpredetermined intervals (e.g., daily, weekly, monthly, etc.). A skilledartisan will appreciate that the request received in step 410 may be arequest to configure embedded computing platform 110 to perform someaction automatically. For example, the request could configure embeddedcomputing platform 110 to collect specified medical data every week. Inthis example, after receiving the request, embedded computing platformwould collect the specified medical data every week automaticallywithout waiting for a request.

In some embodiments, embedded computing platform 110 can be configuredto perform some action automatically when a triggering event occurs. Forexample, embedded computing platform 110 may determine that medicaldevice 100 has malfunctioned, that some readings from the patient areabnormal, that some patient readings have crossed some predeterminedthresholds, etc. When such a triggering event occurs, embedded computingplatform 110 may proactively send collected medical data by email to thehealthcare provider system 210, without waiting for a request. Thehealthcare provider system 210 may set up such triggers by sendingappropriate commands to the medical device 100 by email.

In Step 430 of FIG. 4, embedded computing platform 110 sends thecollected medical data via an email message. As part of this step,embedded computing platform 110 sends the collected medical data toemail server 220 via network 230 as an email message. The collectedmedical data may be formatted according to the defined protocol, asdiscussed above. A skilled artisan will appreciate that the collectedmedical data may constitute a confirmation or notification that embeddedcomputing platform 110 has performed some action. Further, a skilledartisan will appreciate that the collected medical data may be empty(e.g., no notification or confirmation is desired). In one embodiment,embedded computing platform 110 may be adapted to send the data withoutperforming analysis (i.e., send the raw collected data). In anotherembodiment, embedded computing platform 110 may be adapted to performanalysis prior to sending the collected medical data. For example,embedded computing platform 110 may generate reports, charts, trendingor other quantitative analysis, web pages, applets to view the data,alerts, notifications, etc. that are sent in lieu of or along with thecollected medical data. In yet another embodiment, embedded computingplatform 110 may be adapted to generate medical images that are to besent. For instance, embedded computing platform 110 may be configured togenerate medical images using the Digital Imaging and Communications InMedicine (DICOM) format. DICOM was established in 1992 and is thestandard for exchanging medical images in a digital format. These imagescan then be sent to email server 220. A skilled artisan will appreciatethat medical images of any format may be generated in embodiments of thepresent invention. Further, in the preferred embodiment, embeddedcomputing platform 110 emails the collected medical data, analysis, orimages to email server 220 using the SMTP or IMAP protocols. A skilledartisan would appreciate that embedded computing platform 110 may sendthe medical data, analysis, or images to email server 220 also by usingthe protocols discussed above.

FIG. 5 illustrates a flowchart of an exemplary process by which ahealthcare provider system 210, and particularly the provider computingplatform 211 (FIG. 3) of such a system, requests and receives medicaldata in some embodiments of the present invention. Although the steps ofthe communication process are described as being performed in aparticular order, one skilled in the art will appreciate that thesesteps may be performed in a modified or different order, or in anembodiment utilizing less than all of the steps described below.Further, one or more of the steps in FIG. 5 may be performedconcurrently or in parallel.

First, as discussed above, provider computing platform 211 requestsperformance of some action (Step 510). In a preferred embodiment, thehealthcare provider submits the request using a web page, and therequest is transmitted to email server 220 over the Internet. The webpage may be a dedicated web page for a healthcare provider program.Special log-ins may also be provided such that only members can submitrequests. A skilled artisan will appreciate that the healthcare providercan input information regarding the request using any known inputmechanism provided by one or more web pages or other user interface,such as pull-down menus, text boxes, selection boxes, hyperlinks, mobileapplications, and the like. Further, a skilled artisan will appreciatethat the request may also be inputted by use of a dedicated softwareprogram, application, device, etc. For example, the requests may beinputted by use of an applet, plug-in, extension, add-on, etc. A skilledartisan would appreciate that, for example, that medical device 100could provide an applet that could be used to generate requests andprovider computing platform 211 may download the applet and use theapplet to create the requests. One of ordinary skilled in the art wouldappreciate that the web page accessed by provider computing platform 211could invoke the applet to be downloaded. Similarly, a plug-in,extension, or add-on could be installed on computing platform 211 and beused to generate requests.

Moreover, the request may be formatted according to the definedprotocol, as discussed above. For example, once a human operatorspecifies the target medical device and the type of data to becollected, application software may transform these selections into anappropriately formatted and addressed email message that can beinterpreted by the medical device 100. In one embodiment, theapplication software is a web-based application hosted on a webapplication server (see FIG. 10B).

The request from the healthcare provider is then sent to email server220 over network 230. In the preferred embodiment, the requests are sentas emails using the SMTP or IMAP protocols. In an alternate embodiment,provider computing platform 211 automatically sends a request forperformance of some action without waiting for a request from thehealthcare provider. In this embodiment, provider computing platform 211can be configured to send requests to medical device 100 atpredetermined intervals (e.g., daily, weekly, monthly, etc.). Moreover,if the healthcare provider is not already registered, the healthcareprovider may also register with the system at this point, and may begiven a membership ID and/or password. Information supplied by thehealthcare provider during and after registration is maintained inpatient database 221. Further, a skilled artisan will appreciate that avariety of other protocols could be used in embodiments of the presentinvention. For example, FTP, FTPS, SSH, HTTP, HTTPS, VoIP, GPS, CDMA,GSM, etc. may be used.

Next, provider computing platform 211 receives the requested medicaldata (Step 520) from email server 220, which receives the collectedmedical data from medical device 100. In the preferred embodiment,provider computing platform 211 receives the medical data as an emailmessage from email server 220 using the POP protocol. Provider computingplatform 211 may, in one embodiment, periodically check or request emailserver 220 to send any emails or medical data that are to be sent toprovider computing platform 211. In another embodiment, email server 220sends emails or medical data directly to provider computing platform 211without waiting for a request. That is, in such an embodiment, providercomputing platform 211 does not periodically request or check for emailsor medical data but receives the emails or medical data directly fromemail server 220 as they are received. Moreover, in an alternativeembodiment, email server 220 does not send all the data to providercomputing platform 211. Email server 220 stores the received medicaldata and sends a notification to provider computing platform 211 thatmedical data has been received. The provider computing platform 211 maythen provide direct access to the medical data stored at email server220 or may temporarily download a copy of the medical data as desired. Askilled artisan would appreciate that many modifications of the aboveare possible in embodiments of the present invention. For instance,provider computing platform 211 after temporarily downloading a copy ofthe medical data can request that email server 220 delete its copy ofthe medical data or the deletion can occur automatically.

In addition, in one embodiment, healthcare provider system 210 comprisesan application server and a client device. In this embodiment, providercomputing platform 211 is part of the application server and theapplication server can be located inside or outside the medicalinstitution. As such, email server 220 sends any medical data toapplication server. Then application server analyzes the medical data(see step 530 below) and sends client device a notification (discussedbelow). Alternatively, application server can just store and analyze thereceived medical data without sending a notification to the clientdevice such that the client device can access the data at any timedesired. In another embodiment, healthcare provider system 210 comprisesonly a client device. In this embodiment, there is no application serverand email server 220 sends any medical data to the client devicedirectly. As such, the client device analyses the medical data (see step530 below). Further, a skilled artisan would appreciate that providercomputing platform 211 may receive the medical data from email server220 also by using the various protocols discussed above.

The received medical data is then analyzed (Step 530). As part of thisstep, a healthcare provider reviews the received medical data. A skilledartisan will appreciate that the received medical data may also beparsed based on the defined protocol, as discussed above. In theembodiment including the application server, the application serverreceives the medical data from email server 220 and analyzes the data.The application server may create reports, charts, alerts, web pages,etc. for viewing by the healthcare provider. The reports, alerts,charts, web pages, etc. may relate to the status of medical device 100,status of patients connected to medical device 100, malfunctionsassociated with medical device 100, etc. The application server also mayalso create a webpage which would enable the viewing of, and alterationto the functions and performance parameters of medical device 100. Afterthe application server has analyzed the medical data, a notification canbe sent to a client device associated with a healthcare provider. Thenotification notifies the healthcare provider that medical data has beenreceived and analyzed. The notification can be sent to device, such as amobile phone, pager, personal digital assistant, computer, or the like,associated with a healthcare provider. In the embodiment where theanalysis is performed by medical device 100, the application server cansend the notification without performing the analysis. Subsequently, thehealthcare provider can access the medical data. For instance, thehealthcare provider may access a secure web page provided by theapplication server to view any reports, charts, alerts, etc. that weregenerated in response to the received medical data. Alternatively, theapplication server can store the received medical data and the analysiswithout sending a notification to the client device. In that case, theclient device can access the data and analysis as discussed above whendesired.

In the embodiment where there is no application server, the clientdevice performs the analysis discussed above. In this embodiment, theclient device alerts the healthcare provider directly that medical datahas been received and analyzed. In the embodiment where the analysis isperformed by medical device 100, the client can alert the healthcareprovider without performing the analysis. The healthcare provider thencan access the analyzed medical data via the client device.Alternatively, the client device may send a notification to a device,such as a mobile phone, pager, personal digital assistant associatedwith the healthcare provider and then the healthcare can access theanalyzed medical data via the client device.

A skilled artisan would appreciate that, similar to the disclosure abovefor generating requests, the received medical data can also be viewed bythe use of a dedicated software program, application, device, applet,plug-in, extension, add-on, etc. A skilled artisan would appreciate thata variety of graphs, reports, charts, etc. can be used to view thereceived medical data. For instance, a line graph or chart can be usedto view medical data monitored from a ventilator. As another example, adisplay using an applet may be used to display trending data receivedfrom a ventilator. The applet could be generated by medical device 100,application server, or the client device as discussed above.

FIG. 6 illustrates an exemplary system environment 600 for providingmedical charting in some embodiments of the present invention. Similarto system 200 above in FIG. 1, system 600 may comprise multiple computersystems, such as a, a healthcare provider system 210, a medical device100 containing a data sever 105, and an email server 220. In addition,system 600 contains a charting system 610. These various components maybe connected and communicate with one another through any suitablenetwork 230, including the Internet.

Charting system 610 is maintained by a medical institution. Chartingsystem 610 is used by a medical institution to chart medical datacollected from patients. One example of a charting system is ClinivisionMPC Software that allows for the download of data from the PuritanBennett® Ventilators directly to the charting device computer. Theventilator data is automatically integrated into the patient chartreport, and users can create ventilator flow sheet reports.

However, one problem with current charting systems, is that medicaldevice 100 must be configured to output data in a specified format sothat the medical data can properly be processed by the charting system.For example, the Puritan Bennett ventilators, discussed above, must beconfigured to output medical data in a specified format that can beprocessed by the Clinivision charting software. As such, if the chartingsoftware is modified or a different charting software product is used,medical device 100 would have to be re-configured to output medical datain a different format. This can be done by replacing medical device 100with a different medical device or manually updating the functioning ofmedical device 100 by uploading a different version of the software thatenables outputting the medical data in a different format. This can betroublesome if multiple medical devices have been installed becausemultiple medical devices may have to be replaced or updated manually.

In one embodiment, medical device 100 may be re-configured to outputmedical data in a different format electronically. Similar to thediscussions above, medical device 100 is configured to communicate withemail server 220. Email server 220 is configured to communicate withhealthcare provider system 210 which is configured to communicate withcharting system 610. As such, medical device 100 can be configured tooutput medical data in a standard format to email server 220. Then whenthe medical data is communicated to healthcare provider system 210,healthcare provider system 210 can be adapted to format the receivedmedical data in a specified format and transfer the formatted medicaldata to charting system 610 such that charting system 610 can processthe medical data. This embodiment enables the installation of adifferent charting program without re-configuring medical device 100.Medical device 100 can still communicate medical data in a standardformat and healthcare provider system 210 can be reconfigured to formatthe medical data in a different format as may be needed by the differentcharting program.

To enable proper reformatting of the received medical data, healthcareprovider system 210 can be adapted to map the received medical data in astandard format to medical data in a specified format for chartingsystem 610. That is, healthcare provider system 210 may have a mappingtable that associates medical data in the standard format to the relatedvariables, fields, or function calls of charting system 610. A skilledartisan will appreciate that this embodiment will work if healthcareprovider system 210 includes an application server or does not includean application server, as discussed above. If healthcare provider system210 includes an application server, then application server can beconfigured to re-format the medical data as needed. If healthcareprovider system 210 does not include an application server, then theclient device can be configured to re-format the data and transfer thedata to charting system 610. A skilled artisan will also appreciate thatthe standard format can be any format desired, even a format that can bedirectly processed by a particular charting system.

In another embodiment, medical device 100 can be updated to outputmedical data in a specified format. For example, the ventilators, asdiscussed above, that output medical data in a specified format forprocessing by the Clinivision charting software can be updated. In thisembodiment, as discussed above, medical device 100 can be configured toreceive a request from email server 220. In this embodiment, the requestmay include a software update for medical device 100. This softwareupdate would configure medical device 100 to output the medical data ina different format. A skilled artisan will appreciate that similarsoftware updates can also be sent to healthcare provider system 210 insome embodiments of the present invention. For example, if healthcareprovider system 210 includes an application server and a new chartingprogram is now being used, a software update can be sent to theapplication server to provide mapping of medical data to the formatneeded for the new charting program. Similar updating can also beprovided if healthcare provider system 210 does not include anapplication server and includes only a client device.

Conditional language, such as, among others, “can,” “could,” “might,” or“may,” unless specifically stated otherwise, or otherwise understoodwithin the context as used, is generally intended to convey that certainembodiments include, while other embodiments do not include, certainfeatures, elements and/or steps. Thus, such conditional language is notgenerally intended to imply that features, elements and/or steps are inany way required for one or more embodiments or that one or moreembodiments necessarily include logic for deciding, with or without userinput or prompting, whether these features, elements and/or steps areincluded or are to be performed in any particular embodiment.

Any process descriptions, elements, or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or steps in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved, as would be understood by those skilled in the art.

All of the methods and processes described above may be embodied in, andfully automated via, software code modules executed by one or moregeneral purpose computers or processors. The code modules may be storedin any type of computer-readable medium or other computer storagedevice. Some or all of the methods may alternatively be embodied inspecialized computer hardware. In addition, the components referred toherein may be implemented in hardware, software, firmware, or acombination thereof.

The disclosed features may be implemented in various environments,including computer-based environments, such as personal computers,workstations, servers, laptops, personal digital assistants (PDAs),mobile phones, handheld devices, and other computing devices,workstation, networked and other computing-based environments with oneor more customers. The present invention, however, is not limited tosuch examples and embodiments of the invention may be implemented withother platforms and in other environments.

By way of example, some embodiments of the invention may be implementedusing conventional personal computers (PCs), desktops, hand-helddevices, multiprocessor computers, pen computers, microprocessor-basedor programmable customer electronics devices, minicomputers, mainframecomputers, personal mobile computing devices, mobile phones, portable orstationary personal computers, palmtop computers or the like. As usedherein, the term “computing system” is intended to encompass a singlecomputer or computing device, and is also intended to encompass acollection of computers or computing devices that interact with eachother (e.g., over a network). The term “server” is intended to encompassany computing system that responds (or is programmed or configured torespond) to requests by sending or “serving” information. The term“node” is intended to encompass a computing system that is addressableon a network.

The storage media referred to herein symbolize elements that temporarilyor permanently store data and instructions. Although storage functionsmay be provided as part of a computer, memory functions can also beimplemented in a network, processors (e.g., cache, register), orelsewhere. Various types of storage mediums can be used to implementfeatures of the invention, such as a read-only memory (ROM), a randomaccess memory (RAM), or a memory with other access options. Further,memory functions may be physically implemented by computer-readablemedia, such as, for example: (a) magnetic media, like a hard disk, afloppy disk, a magnetic disk, a tape, or a cassette tape; (b) opticalmedia, like an optical disk (e.g., a CD-ROM), or a digital versatiledisk (DVD); (c) semiconductor media, like DRAM, SRAM, EPROM, EEPROM,memory stick, and/or by any other media, like paper.

Some embodiments of the invention may also include computer programproducts that are stored in a computer-readable medium or transmittedusing a carrier, such as an electronic carrier signal communicatedacross a network between computers or other devices. In addition totransmitting carrier signals, network environments may be provided tolink or connect components in the disclosed systems. Networkingenvironments are commonplace in offices, enterprise-wide computernetworks, intranets and the Internet (i.e., the World Wide Web). Thenetwork may be a wired or a wireless network. To name a few networkimplementations, the network may be, for example, a local area network(LAN), a wide area network (WAN), a public switched telephone network(PSTN), an Integrated Services Digital Network (ISDN), an infrared (IR)link, a radio link, such as a Universal Mobile Telecommunications System(UMTS), Global System for Mobile Communication (GSM), Code DivisionMultiple Access (CDMA), or a satellite link.

Transmission protocols and data formats are also known, such as, forexample transmission control protocol/internet protocol (TCP/IP), hypertext transfer protocol (HTTP), secure HTTP, wireless applicationprotocol, unique resource locator (URL), unique resource identifier(URI), hyper text markup language (HTML), extensible markup language(XML), extensible hyper text markup language (XHTML), wirelessapplication markup language (WML), Standard Generalized Markup Language(SGML), etc. Such features may be utilized to implement some embodimentsof the present invention, as disclosed herein.

Moreover, to comply with HIPAA, data may be communicated in embodimentsof the present invention using known encryption and decryptiontechniques. For example, FIG. 7 shows an exemplary encryption system forthe preferred embodiment of the present invention. As shown in FIG. 7(7A and 7B), communication from medical device 100 (e.g., ventilator) toemail server 220 and communications from email server 220 and healthcareprovider system 210 may be encrypted using the secure socket level (SSL)protocol. This type of encryption can be used in both embodimentsrelating to healthcare provider system 210. That is SSL can be used ifhealthcare provider system 210 includes only a client device, as shownin FIG. 7A, or if healthcare provider system 210 includes an applicationserver and a client device, as shown if FIG. 7B. In the embodiment withthe application server, as shown in FIG. 7B, SSL may also be used incommunications between the application server and the client device.

Further, as also shown in FIG. 10, on top of the SSL level, allcommunication from and to medical device 100 are preferably protectedusing ASCII based security measures. In one embodiment, three layers ofASCII based security based measures may be used. The first layer mayrelate to cryptographic hash functions, such as MD5. The second levelmay relate to data blocking and stuffing. The third level may relate toprivate-key stream ciphering. Modifications and variations of theselayers are possible in embodiments of the present invention.Additionally, a skilled artisan will appreciate that a variety of otherencryption algorithms may be used in embodiments of the presentinvention.

In the particular embodiment shown in FIG. 10B, the application softwarewhich runs on the web application server is responsible for at least thefollowing tasks: (1) transforming user selections made via anInternet-connected web browser and a web page into an appropriatelyformatted request message, such as an email, to send to the designatedmedical device 100; (2) sending this request message via the emailserver 220 to the medical device 100; (3) receiving the correspondingreply message, such as an email, generated by the medical device 100,and parsing this reply message to extract the requested data; (4)storing the extracted data in a database in association with the requestmessage and the healthcare entity that generated the request, and (5)making this data, and other collected data, available via web-basedinterface.

It should be emphasized that many variations and modifications may bemade to the above-described embodiments, the elements of which are to beunderstood as being among other acceptable examples. All suchmodifications and variations are intended to be included herein withinthe scope of this disclosure. Further, nothing in the foregoingdisclosure is intended to imply that any particular component,characteristic or process step is essential.

1. A computer-implemented method of communicating with a client systemover a network, the method comprising: receiving, by a network deviceand from the client system over the network using a first protocol, anemail message comprising a command; formatting the received emailmessage so that the command can be communicated to a medical apparatususing a second protocol; transmitting the command to the medicalapparatus, wherein the network device is physically connected to themedical apparatus; receiving a response from the physically connectedmedical apparatus after the physically connected medical apparatus hasprocessed the command; generating a response email message comprisingthe received response; generating a report related to the receivedresponse; and transmitting the response email message and the report tothe client system over the network.
 2. The method of claim 1, whereinthe physically connected medical apparatus is a ventilator.
 3. Themethod of claim 1, wherein the network device is located within amedical institution.
 4. The method of claim 3, wherein the medicalinstitution includes a firewall.
 5. The method of claim 1, furthercomprising storing the received response in a data storage locatedwithin the network device.
 6. A computer-implemented method ofcommunicating with a client system over a network, the methodcomprising: receiving, by a network device, medical data from a medicalapparatus, wherein the medical apparatus is physically connected to thenetwork device; generating an applet for displaying the received medicaldata; generating an email message comprising the received medical data;and sending the email message and the applet to the client system overthe network.
 7. The method of claim 6, wherein the network devicefurther generates reports related to the medical data and performstrending analysis on the medical data.
 8. The method of claim 6, whereinthe medical apparatus is a ventilator.
 9. The method of claim 6, whereinthe network device further stores the medical data.
 10. A device forconnecting a medical apparatus to a network, the device comprising: afirst port for physically connecting the device to the medicalapparatus; a second port for connecting the device to the network; adata storage system for storing medical data received from thephysically connected medical apparatus; and a computer system configuredto: receive an email message including a request for medical dataassociated with the physically connected medical apparatus; transmit therequest to the physically connected medical apparatus; receive medicaldata from the physically connected medical apparatus using a firstprotocol; store the received medical data for future analysis; formatthe received medical data for transmission using a second protocol; andgenerate an applet for displaying the received medical data.
 11. Thedevice of claim 10, wherein the physically connected medical apparatusis a ventilator.